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SECURE TOKEN DEVICE ACCESS TO SERVICES PROVIDED BY 
AN INTERNET SERVICE PROVIDER (ISP) 

Technical Field of the Invention 

5 The present invention relates generally to data processing systems and more 

particularly to secure token device access to services provided by an Internet Service 
Provider (ISP). 

Background of the Invention 

10 An ISP is a vendor who provides customers with access to the Internet. 

Examples of ISPs include America Online (AOL), CompuServe and the Microsoft 
Network (MSN). In addition to providing access to the Internet, ISPs may also provide 
additional services to their customers, including chat rooms, news services, electronic 
mail messaging and bulletin board services. 

1 5 ISPs provide access to the Internet to customers by employing one or more 

Internet servers. These servers are directly connected to the Internet and act as conduits 
for customers to access web pages resident on other servers on the Internet. Typically, a 
customer uses a conventional modem to place a call to a designated ISP server. The 
modem need not be a conventional modem but may be instead, a cable modem or a 

20 wireless modem. The ISP server answers the call and a connection is established 

between the server and the customer's computer. After this connection is established, 
the customer is prompted to login. In particular, the customer is prompted usually to 
enter a user ID and a password. The information entered by the customer is compared to 
data stored in a database with the ISP to determine whether the user is who the user 

25 purports to be. If the customer provides the proper information and has sufficient 
privileges, the customer is granted access to the Internet. 

There are a number of drawbacks associated with the above-described 
conventional approach to providing Internet access to customers. First, the Internet 
Protocol (IP) is used for messaging addressing on the Internet and the protocol is a 

30 connectionless protocol. As such, the protocol does not support the persistent storage of 
contextual information. Thus, any contextual information associated with one customer 
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session on the Internet is not carried forward to the next customer session. Each session 
must start anew in creating a context. Second, the conventional approach to providing 
access to the Internet by ISPs is susceptible to fraud. If a party can obtain a user ID and 
password for a user, the party can gain access to the Internet via the user's account. 
5 Third, most ISPs currently provide only one variety of service such that all customers 
are offered this single variety of service. For example, all customers may be offered full 
access to a complete range of services provided by an ISP and all customers may be 
charged a flat fee for a designated time frame of service (e.g. for a month of service or a 
year of service). Customers who use the services more frequently than other customers 
10 are not charged additional amounts. Hence, there is a lack of flexibility in the pricing 
and service options available to customers from ISPs in conventional systems. 



Summary of the Invention 

The present invention addresses the limitations of the prior art by providing users 

15 with secure token device access to services offered by ISPs. "Secure token devices" are 
devices such as smart cards and ibuttons that hold currency tokens and other information 
in a secure fashion. Preferably, the secure token device is of a size, shape and weight 
that it is easily carried by a user. The secure token device may even be wearable by a 
user. When a user wishes to access services provided by an ISP, the user puts a secure 

20 token device in communication with a reader. The reader is a device that is configured 
to read and communicate with the secure token device. The reader is coupled to a 
computer system, such as a personal digital assistant (PDA), workstation or a personal 
computer (PC). When the user places the secure token device in or against the reader 
(depending on the type of reader), the reader recognizes the insertion of the secure token 

25 device and prompts the computer system to begin communicating with the secure token 
device. The computer system may seek to verify that the user is the proper owner of the 
secure token device. To that end, the computer system may request that the user enter a 
personal identification number (PIN). The user enters a PIN and the PIN is compared 
with a PIN value that is stored on the secure token device. If the PIN value entered by 

30 the user matches the PIN value on the secure token device, the computer system verifies 
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that the user is the owner of the secure token device and the process of accessing the ISP 
services may be initiated. 

The secure token device may hold identification information that is globally 
unique across geographic and political boundaries. This identification information is 
5 held securely on the secure token device. It is difficult for a party to physically access 
the identification information. The secure token device serves as a physical token of 
authenticity for the party. In order to fraudulently use the secure token device, a party 
must both physically take the secure token device and also be aware of the PIN 
associated with the user of the secure token device. Hence, the use of the secure token 

1 0 device helps to decrease the probability of fraud. 

Contextual information (i.e., a context) may be stored on the secure token device 
of the user. The context may, for example, identify user preferences and configuration 
information. When a user seeks to access the services of the ISP, the context from a 
previous session may be restored by retrieving the context from the secure token device. 

1 5 This ability to preserve context enhances the services provided to the user and eliminates 
the need for the user to recreate a context each time the user accesses ISP services. 

The secure token device may also support various electronic banking or 
electronic commerce mechanisms that facilitate the exchange of electronic currency. 
The secure token device may be used in realizing payment for services provided by 

20 ISPs. The user may download currency tokens from the secure token device to the ISP 
to cover expenses associated with the services provided during a given session. This 
ability to receive payment for services during a session with the user enhances the ability 
of ISPs to tailor pricing schemes on a per use basis. An ISP may charge a user for the 
services rendered during a given session as opposed to using a flat rate scheme over an 

25 extended time period, such as a month or a year. Thus, users are charged on the basis of 
the resources they consume rather than on a flat rate basis. 

The secure token device of a user may contain personal information regarding a 
user, such as name, address, and credit card account information. The user has the 
ability to customize what portions of this personal information may be accessed by a 

30 service provider. Hence, the user may determine that an ISP should only be given 
access to the user's name and address and should not given access to the user's credit 
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card account information. For another service provider, the user may grant the service 
provider full access to all of the personal information. This approach has the added 
benefit of storing personal information more securely than instances where the personal 
information is stored on database maintained by an ISP. It should be noted, however, 
that ISPs may store additional information on secure token devices that is not readily 
accessible to users. A further benefit of this approach is that it gives the user control 
over what personal information the user grants to respective parties. Still, further, the 
storage of personal information on the secure token device facilitates companies to 
develop loyalty marketing programs, such as frequent flier programs. The frequent flier 
miles of a user may be stored on the secure token device, added to the storage on the 
secure token device and redeemed from the secure token device. 

Brief Description of the Drawings 

An illustrative embodiment consistent with the principles of the present 
invention will be described below relative to the following drawings. 

FIGURE 1 is a block diagram that illustrates hardware components used to 
practice the illustrative embodiment of the present invention. 

FIGURES 2A and 2B illustrate the exemplary layout for a smart card to be used 
in the illustrative embodiment of the present invention. 

FIGURE 2C illustrates the contacts on the smart card of FIGURE 2A in more 

detail. 

FIGURE 3 illustrates an example of an ibutton ring to be used in the illustrative 
embodiment of the present invention. 

FIGURE 4 is a block diagram illustrating computing components on the secure 
token device. 

FIGURE 5 is a block diagram illustrating components of the computer system of 
FIGURE 1 in more detail. 
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FIGURE 6 illustrates the various Java packages that are found on the secure 
token device. 

5 FIGURE 7 A illustrates object classes that are supported by the computer system 

of FIGURE 1. 

FIGURE 7B illustrates object-classes that are part of the CardTerminal 
component. 

10 

FIGURE 7C illustrates object-classes that are part of the CardAgent component 

FIGURE 7D illustrates object-classes that are part of the CardIO component. 

15 FIGURE 8 A illustrates the logical format of a command APDU. 

FIGURE 8B illustrates the logical format of a response APDU. 

FIGURE 9 is a flow chart that illustrates the steps that are performed when a user 
20 logs in via a secure token device. 

FIGURE 10 is a flow chart illustrating the steps that are performed when a user 
desires to access services provided by an ISP. 

25 FIGURE 1 1 is a flow chart illustrating the steps that are performed when an ISP 

seeks context information from a user. 

FIGURE 12 illustrates the logical organization of a user profile. 

30 FIGURE 13 is a flow chart illustrating the steps that are performed to restore a 

context in the illustrative embodiment of the present invention. 
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FIGURE 14 is a flow chart illustrating the steps that are performed in billing a 
customer for services rendered by an ISP. 

Detailed Description of the Invention 

In the illustrative embodiment consistent with the present invention, a user gains 
access to services provided by an ISP by employing a secure token device, such as a 
smart card or an ibutton (such as produced by Dallas Semiconductor Corporation). The 
secure token device is a secure electronic device that holds globally unique identification 
information regarding the user. The user may be required to enter a password or PIN to 
verify that the user is the same party whose identification information is stored on the 
secure token device. The secure token device is programmed to support two-way 
verification between the user and the ISP. Specifically, the user must prove that the user 
is who the user purports to be, and the ISP must prove that the service is what it purports 
to be. 

The secure token device may hold contextual information on behalf of the user. 
The contextual information may capture the context of a previous session with the ISP. 
When the user again gains access to the services of the ISP, the context from the 
previous session may be restored. For example, user preferences and other contextual 
information that were entered in a previous session may be carried forward into the new 
session. 

The secure token device may run multiple programs. The programs may include 
code for facilitating access to the services of an ISP and code for electronic commerce 
transactions. These transactions may entail the exchange of electronic currency in the 
form of tokens. Thus, when the user accesses a web site or other service that requires 
payment for the tendering of goods or services, the user can pay for the goods or 
services using the tokens contained services based on the secure token devices. It should 
be appreciated that the ISPs may serve the role of distributor for distributing the secure 
token devices to customer. 
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The secure token device may hold information regarding the user that is 
potentially sensitive. The user has control over dissemination of this information. The 
user selects what portions of this information are available to respective requesters. 
Different requesters may be granted different permissions. For example, a first requester 
5 may receive a first set of personal information and a second requester may receive a 
second set of personal information that differs from the first set. 

The use of the secure token device enables ISPs to tailor their service offerings 
and billing options to individual users. The users may be offered different service 
options. For example, a first user may be offered a service option where the user is only 
10 permitted to browse the Internet. A second user, in contrast, is offered the ability to 

browse the Internet and to send emails, visit chat rooms and visit news sites. The second 
user may be charged additional amounts for the expanded service. Other types of 
expanded service may include secure email and authenticated connections with other 
users. 

15 Figure 1 is a block diagram that illustrates several of the hardware components 

employed in the illustrative embodiment consistent with the present invention. These 
components include a secure token device 1 0 that is provided for a user. The secure 
token device 1 0 may be any secure device that is capable of holding electronic currency 
tokens, identification information and context information. Preferably, the secure token 

20 device is of an appropriate size, weight and shape to be portable and easily carried by a 
user. Suitable secure token devices include smart cards and ibuttons. A secure token 
device is an integrated circuit card that preferably is sized to fit into a user's wallet or 
purse. Ideally, a smart card is the size of a credit card. The smart card has computer 
components such as a microprocessor and a storage embedded in it. A smart card that 

25 may be used to practice the present invention may comply with the ISO-781 6 standard 
or the EMV integrated circuit card specification. For purposes of the discussion below, 
it is assumed that if a smart card is used as the secure token device, the smart card 
complies with the JavaCard 2. 1 specification as defined by Sun Microsystems, Inc. The 
JavaCard 2. 1 specification requires that the secure token device be capable of running 

30 programs written in the Java™ programming language. Java is a trademark of Sun 
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Microsystems, Inc. Those skilled in the art will appreciate that the programs used to 
practice the present invention may be written in programming language other than 
Java™, including C, C++ and Basic. 

An ibutton is a computer chip that is housed in a cylindrical housing (such as a 
5 steel canister). The housing is designed to withstand the harsh conditions of outdoor 
environments. The ibutton may be incorporated into a ring or other wearable item. For 
instance, ibuttons may be affixed to badges, watches, rings key chains and the like. The 
chip within the housing includes a microprocessor and may also contain computer 
memory, a clock or sensors. Such ibuttons are used by contacting the ibuttons with 

1 0 readers (e.g. "blue dot receptors") that are cabled into the serial ports of associated 

computers. A suitable ibutton for practicing the illustrative embodiment consistent with 
the present invention is the Java™ Ring produced by Dallas Semiconductor Corporation. 

The hardware components used in the illustrative embodiment consistent with 
the present invention also include a reader 12. The reader 12 is a device for facilitating 

15 communications between a computer system 14 and the secure token device 10. The 
reader 12 provides a path for application programs run on computer system 14 to 
communicate with the secure token device 1 0. Preferably, when the secure token device 
is a smart card, the reader 12 is compliant with the OpenCard standard. The OpenCard 
standard is a standard that provides for inter-operability of secure token device 

20 applications across devices, such as network computers, laptop computers, desktop 
boxes, desktop computers, cellular phones and personal digital assistants (PDAs). A 
number of different commercially available card terminals may be utilized as the reader 
12 when the secure token device is a smart card. A suitable reader is the IBM 594A card 
terminal. When the secure token device 10 is an ibutton, a suitable reader is the DS1402 

25 blue dot receptor from Dallas Semiconductor Corporation. The reader may also be a 
proximity detector. 

The computer system 14 may be a PDA, a personal computer (PC) or a 
workstation. The configuration of the computer system 14 will be described in more 
detail below. The computer system 14 may communicate with a remote server computer 

30 system 1 6 via a communications link 15. The communications link 1 5 may be, for 

example, a telephone line connection. More generally, the communication link 15 may 
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be a wireless connection, a cable modem connection, a satellite connection or a direct 
connection. The remote server 16 is controlled by the ISP and provides the user with 
access to the Internet. 

Figures 2A and 2B illustrate an exemplary physical layout for a smart card to be 
5 used as the secure token device 1 0. The secure token device 1 0 is formed on a plastic 
substrate 20. The front of the card (as shown in Figure 2A) includes a number of 
electrical contacts 1 6 which facilitate communications with the smart card. Figure 2C 
shows these contacts 16 in more detail. Contact 24 is used to connect with the power 
source that is provided by the smart card reader. Contact 26 is to be coupled to a ground 

10 connection on the smart card reader. Contact 28 is used for input/output of data packets 
(described below). Contact 30 is used to reset the smart card, and contact 32 is used for 
a check procedure performed on the smart card to ensure that the smart card is operating 
properly. Optional contacts 34, 36 and 38 are also provided. The front of the smart card 
may also include an embossing area 1 8 where the user may sign the smart card. The 

1 5 back of the smart card (as shown in Figure 2B) may include a magnetic strip 22 for 

holding information that is magnetically encoded. In some applications, the smart card 
may be used as an ID badge that permits a user access to certain locales. The magnetic 
strip may hold information that permits the user to gain access to a secure area or other 
locales, for example. 

20 Those skilled in the art will appreciate that the physical layout of the smart card 

shown in Figures 2A-2C is intended to be merely illustrative and not limiting of the 
present invention. The secure token device used to practice the present invention may 
have a different physical configuration with additional components or fewer components 
than shown in Figures 2A-2C. 

25 Figure 3 depicts an example of the physical layout of a Java Ring 35 that is 

suitable for practicing the present invention. The Java™ Ring 35 includes a steel 
cylindrical housing 37 that houses an integrated circuit (IC) 41 that contains a 
microprocessor and a storage (i.e. a computer memory). The Java™ Ring 35 also 
includes a ring portion 39 that enable a user to wear the whole device like an ordinary 

30 ring. As will be described in more detail below, the processor and storage work in 
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conjunction to runs programs that help facilitate the illustrative embodiment of the 
present invention. 

Figure 4 shows a block diagram of the computer architecture of the secure token 
device 10. The computer architecture includes a microprocessor 40 and a storage 42. 
5 The storage 42 may be formed by different types of devices, including random access 
memory (RAM), read only memory (ROM), and electrically erasable programmable 
read only memory (EEPROM) devices. Those skilled in the art will appreciate that the 
storage 42 may also include other types of storage devices. The storage 42 holds a 
number of types of data and programs that may execute on the microprocessor 40. In 

1 0 the illustrative embodiment of the present invention, it is assumed that the processor 40 
on the secure token device 10 is capable of running programs written in the Java™ 
programming language. An "applet" is a special type of program that runs inside an 
applet viewer, a web browser or a secure token device. The storage 42 holds a copy of 
an ISP applet 44. The ISP applet 44 enables the secure token device 10 to communicate 

15 with an ISP and to receive services from an ISP. Those skilled in the art will appreciate 
that the secure token device may instead run programs in programming languages other 
than Java™. 

The storage 42 also holds a copy of a banking applet 46 that allows the secure 
token device 10 to be utilized in electronic commerce transactions. As will be described 

20 in more detail below, in the illustrative embodiment, the banking applet 46 allows the 
secure token device to be used with a MONDEX system or other type of electronic 
commerce system. The secure token device 10 may hold tokens representing units of 
electronic currency that may be used to pay for goods and services. The banking applet 
provides the intelligence for participating in such transactions. The storage 42 may also 

25 hold other applets 4 1 . 

The storage 42 holds a copy of a user profile 48. The user profile contains 
personal information regarding a user. Preferably, as will be described in more detail 
below, the user profile 48 complies with the Open Profiling Standard (OPS) and/or the 
Information & Content Exchange (ICE) protocol. 
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The storage 42 additionally holds the JavaCard API as defined in the JavaCard 
2.1 specification. In instances where the secure token device is not a smart card, other 
similar API sets may be alternatively used. The JavaCard API is an application program 
interface that provides a broad range of functionality for the secure token device 10. The 
5 major components of the JavaCard API 50 will be described in more detail below. The 
applets stored on the secure token device 10 may instantiate object classes defined in the 
API to realize desired functionality. The storage 42 holds a copy of a JavaCard virtual 
machine (VM) 52. The JavaCard virtual machine is like a conventional Java virtual 
machine but is streamlined to operate with the memory and processing restrictions that 

10 are found with secure token device 10. The JavaCard VM provides platform 
independence for the Java programs that are run on the processor 40. 

Those skilled in the art will appreciate that the secure token device 10 may hold 
additional programs and data that differ from that shown in Figure 4. 

Figure 5 is a block diagram that shows the components of the computer system 

15 14 in more detail. Computer system 14 includes a central processor unit (CPU) 54 for 
executing instructions. A number of peripheral devices, including a keyboard 56, a 
video display 58, and a mouse 60, may be provided as part of the computer system 14. 
A modem 62 may be provided to allow the computer system to communicate over 
analog telephone lines, and a network adapter 64 may be provided to facilitate the 

20 connection of the computer system 14 to a local area network (LAN). As has been 

discussed above, the computer system 1 4 may also include other components, such as a 
cable modem, for facilitating remote communications with the remote server 1 6. 

The computer system 14 includes both primary storage 68 and secondary storage 
66. The secondary storage 66 may include a number of types of persistent storage. For 

25 example, the secondary storage 66 may include CD-ROM drives, hard disk drives and 
other types of computer-readable mediums. The primary storage 68, likewise, may 
include a number of different types of storage, including DRAM, SRAM, and the like. 
The primary storage 68 holds a copy of an operating system 70. The Solaris® operating 
system is suitable for practicing the illustrative embodiment of the present invention. 

30 "Solaris'* is a registered trademark of Sun Microsystems, Inc. A web browser 72 is 

provided in primary storage 68 to facilitate access to the Internet. Suitable web browsers 
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include Netscape Navigator, Netscape Communicator and Microsoft Internet Explorer. 
It should be appreciated the web browser 72 may include intelligence for processing 
hypertext mark-up language (HTML) documents. A Java™ VM 74 is provided in 
primary storage 68 for interpreting Java programs. The OpenCard API 76 is also found 
5 within the primary storage 68. Additional applications 78, including Java applets, may 
also be stored in the primary storage 68. These applications may instantiate objects of 
the object classes defined in the OpenCard API to realize needed functionality. 

Those skilled in the art will appreciate that various ones of the components 
depicted in Figure 5 as being stored in the primary storage 68 may alternatively be 

10 stored in the secondary storage 66. Those skilled in the art will also appreciate that the 
computer system 14 shown in Figure 5 is intended to be merely illustrative and not 
limiting of the present invention. Further, it should be appreciated that the reader 1 2 
shown in Figure 1 may be integrated as part of the computer system 14. 

The Java™ programming language is object-oriented. It generally supports the 

1 5 arrangement of sets of object classes into packages. The JavaCard API 50 is divided 
into a number of packages 78, as shown in Figure 6. The java.lang package 80 contains 
a number of object classes that are concerned with exceptions, such as run time 
exceptions and security exceptions. The javacard.framework package 82 contains object 
classes for APDUs (defined below), applets, PINs and various system constants. The 

20 j a vacardx. framework package 84 contains object classes relating to file system 

structures. The jacacardx.crypto package 86 holds objects that provide cryptography 
support on the secure token device 10. The javacardx.cryptoEnc package 88 contains 
object classes relating to the DES encryption scheme. 

Programmatic support for use of the secure token device 1 0 is provided on the 

25 computer system 14. The OpenCard API 76 provides a number of interfaces that 

facilitate communications with the secure token device. Figure 7 A depicts the major 
components of the OpenCard API 76. The CardTerminal component 90 abstracts the 
readers (also known as card terminals) that help to interface the secure token device 1 0 
with the computer system 14. Each reader (see Figure 7B) is represented by an instance 

30 of the CardTerminal object class 85. A CardTerminal Factory 83 object class is defined 
to instantiate instances of the CardTerminal object class. The CardTerminalRegistry 
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object class 81 (Figure 7B) is defined as part of the CardTerminal component 90. Only 
a single instance of this object class exists and this instance serves as the system-wide 
registry. Register() and unregister() methods are provided for this object class to 
dynamically add or remove card terminals from the registry. A slot object class is 
5 defined for each slot in a reader. Each instance 87A and 87B of this object class 

represents a physical card slot in a card terminal. A CardID object class 89 is defined in 
the CardTerminal component 90 to represent a secure token device. 

The CardAgent component 92 abstracts an agent that operates on behalf of the 
secure token device 10. A CardAgent object class 91 (See Figure 7C) is defined in this 
package to abstract the functionality of the secure token device. Each agent has a 
separate instance of the object class. Communications between the secure token device 
10 and the computer system 14 pass through the CardAgent. A CardAgent Factory 
object class 93 support instantiation of CardAgent objects 91 and a CardAgent Factory 
Registry object class 95 may be instantiated to hold a registry of all agents. 

The CardIO component 94 contains object classes that are used to support 
input/output relative to the secure token device 10. All application interaction with the 
secure token device 10 takes place through objects of the object classes defined in this 
component 94. A SmartCard object class 97 (See Figure 7D) is defined to represent a 
physical secure token device. Access to the file system on the secure token device 1 0 is 
achieved by mounting a root master file, resulting in an instance of the CardFile object 
class 99A, which is defined as part of the CardIO component 94. An application can 
access other files on the secure token device 10 by instantiating appropriate CardFile 
objects 99B and 99C. Figure 7D show an example where three card file objects are 
instantiated. The CardRandomAccessFile object class 103 defines objects that allow 
programs to access contents of the associated files. 

The secure token device 10 and the computer system 14 communicate by passing 
data packages back and forth. These data packages are known as application protocol 
data units (APDUs). The format for APDUs is defined in the ISO-7816 standard. Each 
APDU contains either a command or a response to a command. A master-slave model 
may be followed where the secure token device 10 plays the slave role and the computer 
system 14 plays the master role. The secure token device 10 always waits for a 
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command APDU from the computer system 14 by way of the reader 12. The secure 
token device 10 then executes the command specified in the command APDU and 
replies to the terminal with a response APDU. A client/server model may also be 
followed wherein the computer system 14 serves as a security server and the secure 
token device 10 serves as a client. 

Figure 8A depicts the logical format of a command APDU 1 00. The mandatory 
header 1 02 encodes the command that is to be encapsulated in the APDU. The header 
102 includes four fields: the CLA field 106, the INS field 108, the PI field 1 10, and the 
P2 field 1 12. The CLA field 106 is a class byte that identifies an object class, such as an 
application program. The INS field 108 is an instruction byte that identifies the 
instruction (i.e. the command). The PI field 110 and the P2 field 1 12 are parameter 
bytes that provide further qualification of the APDU command. These fields 1 10 and 
1 12 are used to pass parameters with the command. 

The command APDU 100 also contains a conditional body 104. The conditional 
body 104 contains three fields: the Lc field 1 14, the data field 1 16, and the Le field 118. 
The Lc field 1 14 holds a value that identifies the number of bytes in the data field 1 1 6. 
The data field 1 16 is used to hold data, and the Le field 1 1 8 identifies a maximum 
number of bytes that are expected in the datafield in the response APDU that is to be 
received after the command APDU 100 is processed. 

Figure 8B shows logical format of a response APDU 101 . The response APDU 
may contain a conditional body 120 and a mandatory trailer 122. The conditional body 
120 includes a data field 124 for holding data. The mandatory trailer 122 contains an 
SWT field 126 and an SW2 field 128. These two fields each hold a respective status 
byte that reflects the status of the command for which the response is sent. 

Figure 9 is a flow chart that illustrates the steps that are performed during initial 
login when a user using secure token device 10 attempts to gain access to computer 
system 14. The role played by the secure token device 10 during login may be encoded 
in one of the applets 41 stored in the storage. Initially, the user places the secure token 
device 10 in position for reading by reader 12 (step 130 in Figure 9). The reader 12 
detects the presence of the secure token device 10 and then informs the computer system 
14 (step 132 in Figure 9). A number of different login options may be followed but, in 
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general, the computer system 14 begins the login process by sending appropriate 
command APDUs via the reader 12 to the secure token device 10. The commands 
prompt the user to enter a PIN value (step 134 in Figure 9). The PIN may be, for 
example, a code constituting between 4 to 8 digits that is uniquely assigned to the user. 
5 The reader 12 may include a keypad that is used to enter the PIN or, alternatively, the 
user may enter the PIN via the keyboard 56 that is part of the computer system 14 (step 
136 in Figure 9). 

The PIN entered by the user is then compared with the PIN value assigned to the 
user (step 138 in Figure 9). In particular, the secure token device 10 holds the proper 

1 0 PIN value for the user within its storage 42 (Figure 4). The PIN value may be stored as 
part of the user profile 48. The JavaCard API 50 defines a PIN object class for holding a 
PIN value, and this object class includes methods for accessing the PIN. These methods 
are used to obtain the proper PIN and to compare the stored PIN with that entered by the 
user. The use of the PIN helps to ensure that the proper party and not an unauthorized 

1 5 party is utilizing the secure token device. If the correct PIN has been entered (see step 
140 in Figure 9), the user is granted access to the computer system 14 (step 142 in 
Figure 9). If the correct PIN is not entered, the user may be given an additional 
opportunity to enter the proper PIN. The information stored on the secure token device 
identifies the maximum number of tries that may be attempted before user is denied 

20 access. Hence, in step 144 of Figure 9, a determination is made whether the maximum 
number of tries has been reached or not. If the maximum number of tries has been 
reached, the user is denied access (step 146 in Figure 9). Otherwise, the process is 
repeated again, beginning with step 1 34 in Figure 9 where the user is prompted to enter a 
PIN. 

25 After login, the user may desire to access services provided by the ISP (step 148 

in Figure 10). For example, the user may double click on an icon associated with the 
ISP or the system may automatically attempt to grant the user access to the ISP services 
once login is completed. A two-way challenge response authentication is then initiated. 
First, the ISP (i.e. remote server 16) issues a challenge to the secure token device 10 to 

30 ensure that the user should be granted access to the ISP services (step 1 50 in Figure 10). 
The secure token device 10 receives the challenge and responds (step 152 in Figure 10). 
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A proper response reveals knowledge of a shared secret (such as an encryption key). 
The ISP applet 44 contains the appropriate intelligence for responding to such a 
challenge. The challenge may be issued by one of the applications 78 stored in the 
primary storage 68 of the computer system 14. If the response is not proper (step 154 in 
5 Figure 10), the services provided by the ISP are not accessed (step 164 in Figure 10). If 
the response, however, is proper, the user is authenticated, and a challenge is issued by 
the secure token device 10 to the ISP (step 156 in Figure 10). The ISP responds to the 
challenge by submitting a response (step 158 in Figure 10). If the response is proper 
(see step 160 in Figure 10), the services provided by the ISP are accessed (step 162 in 
10 Figure 10). In contrast, if the response is not proper, the services are not accessed (step 
164 in Figure 10). Those skilled in the art that multiple two way authentications may be 
performed. 

It should be appreciated that each user has a globally unique ID that is encoded 
on the secure token device. The user ID is unique across geographic and political 

1 5 boundaries. This user ID may be used in formulating the challenge that is issued by the 
ISP. Each ISP also has a globally unique ID. The ISP ID may be used in the challenge- 
response protocol. 

Those skilled in the art will appreciate that a number of different 
challenge/response protocols may be utilized in performing this two-way authentication. 

20 For example, SHA-1 , XOR and other protocols may be used. Moreover, those skilled in 
the art will appreciate that the ISP may be first presented with the challenge rather than 
the secure token device. 

Before the ISP begins providing services or sometime during session where the 
ISP is providing services, the ISP may seek personal information from the user profile 

25 48 stored on the secure token device 10. The format of the user profile 48 will be 

described in more detail below. The ISP begins the process by requesting information 
from the profile 48 (step 166 in Figure 1 1). Permissions are defined for each requester 
that may request personal information of the secure token device 10. These permissions 
identify what portion or subset of profile data may be accessed by the requester. In 

30 response to the request from the ISP, the secure token device 1 0 accesses the 

permissions that are provided for the ISP (step 168 in Figure 1 1). The request identifies 



WO 99/62210 PCT/US99/1 1528 

- 17- 

what information is sought from the secure token device. The secure token device 
determines whether the ISP has the permissions needed to receive the requested 
information (step 170 in Figure 11). If the ISP lacks the appropriate permissions, the 
ISP is denied access (step 1 72 in Figure 11). If the ISP has the appropriate permissions, 
5 the ISP is granted access to the information, and the secure token device 1 0 forwards the 
information to the ISP (step 174 in Figure 11). This information may be forwarded from 
the secure token device 10 to the computer system 14 in encrypted form for security 
purposes. It should be appreciated that the secure token device may partially grant the 
request where an ISP requests information that it is permitted to receive as well as 

10 information it is not permitted to receive. 

Figure 12 shows a logical organization of an illustrative user profile 178. In the 
illustrative embodiment consistent with the present invention, the user profile may 
conform with the Open Profiling Standard (OPS). In accordance with that standard, the 
information contained in the user profile is divided into sections and subsections. In the 

1 5 exemplary case shown in Figure 1 2, the profile 1 78 is divided into a first section 1 80 
and a second section 182. Suppose that the first section 180 contains address 
information and section 1 82 contains credit card information. The first section 1 80 also 
contains a subsection 188. This subsection 188 may contain, for example, a phone 
number. Each statement is a name/value pair. The first section includes statements 1 84 

20 and 1 86 that assign given values to properties. The subsection 1 88 also contains a 
statement 1 90 that assigns a data value to a property. Permissions are granted on a 
section or subsection basis. 

The information contained in the user profile 48 may vary. The user profile may 
contain information such as name, address, and credit card information. In general, the 

25 information is personal to the user. 

As was discussed above, the secure token device 1 0 may be used as a vehicle for 
preserving contextual information. In particular, the context of a given session with an 
ISP may be preserved for later restoration in a subsequent session. The context may 
hold a wide variety of different information. For instance, user preferences regarding 

30 settings and various web sites may be restored in the context. Where the ISP begins a 
session with the user, the ISP requests contextual information from the secure token 
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device 10 (step 192 in Figure 13). The secure token device then provides the context to 
computer system 14, which forwards the information to the ISP at the remote server 16 
(step 194 in Figure 13). The contextual information is used to restore the previous 
context (step 196 in Figure 13). Subsequently, the ISP seeks to store the new context of 
5 the current session with the secure token device 1 0 so that the new context may be 
subsequently restored in the next session (step 198 in Figure 13). The new context is 
sent to the secure token device 10 and the secure token device stores the new context for 
subsequent use (step 200 in Figure 13). 

The secure token device 10 may provide the ability for the user to pay for 

10 services rendered by the ISP during a session with the ISP. As was discussed above, this 
also assists the ISP in tailoring services to a particular user and in charging the user 
based upon resource utilization. Initially, the user seeks an ISP service, such as web 
browsing or electronic mail (step 202 in Figure 14). The ISP then levies a charge for 
user to access the servers (step 204 in Figure 14). The secure token device returns an 

1 5 electronic token representing amount of currency to the ISP (step 206 in Figure 14). As 
was mentioned above, the secure token device 1 0 includes a banking applet 46 that 
supports the ability to respond to requests and to deliver tokens. The banking applet 46 
may support transactions involving MONDEX tokens or other types of electronic 
currency tokens. MONDEX is an electronic transaction system that employs smart 

20 cards for person-to-person payments. MONDEX was developed by National 

Westminster Bank in conjunction with Midland Bank and British Telecom and has been 
in use since July 1995. MONDEX uses tokens of a specified format. 

The ISP receives the tokens and deposits the tokens in an appropriate account 
(step 208 in Figure 14). After receiving payment, the ISP then grants the user access to 

25 the server (step 210 in Figure 14). The Java electronic commerce framework (defined 
by Sun Microsystems, Inc.) is an open platform for development of electronic commerce 
applicators in Java. This framework may be used by the banking applet 46. 

Those skilled in the art will appreciate that a number of different electronic 
transaction systems may be utilized in the present invention. The present invention is 

30 not limited to using MONDEX currency. Moreover, the billing scheme may differ from 
that shown in Figure 14. The timing at which a party is charged for services may differ 
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such that a party is charged after having finished using a service rather than before 
accessing the service. Furthermore, there may be instances where an ISP is required to 
provide change in the form of tokens that are returned to the secure token device 10. 

While the present invention has been described with reference to an illustrative 
5 embodiment thereof, those skilled in the art will appreciate the various changes in form 
and detail may be made without departing from the intended scope of the present 
invention as defined in the appended claims. For example, different varieties of secure 
token devices may be used to practice the present invention. 
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What is claimed: 

1 . In a computer system where a user accesses services provided by a service 
provider during sessions via a connectionless protocol, a method comprising the steps 
5 of: 

providing a secure token device for a user, said secure token device holding 
contextual information that captures a context of a last session the user had with the 
service provider; 

on behalf of the service provider, receiving the contextual information from the 
1 0 secure token device; and 

using the contextual information to restore the context of the last session the user 
had with the service provider during a current session where services are provided by the 
service provider to the user. 

15 2. The method of claim 1 wherein the connectionless protocol is the Internet 
Protocol (IP). 

3. The method of claim 1 wherein the service provider is an Internet Service 
Provider (ISP) that provides the user with access to the Internet. 

20 

4. The method of claim 1 wherein the contextual information identifies a uniform 
resource location. 



25 



5. 
6. 



The method of claim 1 wherein the secure token device is a smart card. 
The method of claim 1 wherein the secure token device is an ibutton. 
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7. In a secure token device, for use by a user in accessing services of a service 
provider via a connectionless protocol during sessions, a method comprising the steps 
of: 

providing contextual information that captures a context of a last session that the 
5 user had with the service provider on the secure token device; 

receiving a request to read the contextual information on behalf of the service 
provider; and 

in response to the requests, outputting the contextual information for use by the 
service provider in restoring the context of the last session in a current session where 
1 0 services are provided by the service provider to the user. 

8. The method of claim 7 wherein the connectionless protocol is the Internet 
Protocol (IP). 

15 9. The method of claim 7 wherein the service provider is an Internet Service 
Provider (ISP) that provides the user with access to the Internet. 

10. The method of claim 7 wherein the contextual information identifies a web site. 

20 11. The method of claim 7 wherein the secure token device is a smart card. 



12. The method of claim 7 wherein the secure token device is an ibutton. 
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13. In a secure token device that interfaces with a computer system, wherein a user 
accesses services provided by a service provider on the computer system, a method 
comprising the steps of: 

providing personal information about the user in the storage of the secure token 

5 device; 

establishing what portion of the personal information is permitted to be given to 
the service provider upon request; 

receiving a request from the service provider at the secure token device to obtain 
at least some of the personal information about the user; and 
1 0 in response to the request, sending to the service provider only information from 

the portion of the personal information that is permitted to be sent to the service 
provider. 

14. The method of claim 1 3 wherein the information that is sent to the provider 
1 5 includes less than all of the information requested. 

15. The method of claim 13 wherein the user establishes the portion of the personal 
information that is permitted to be given to the service provider upon request. 

20 16. The method of claim 13 wherein when the service provider requests only 
information that is not permitted to be given to the service provider, the request is 
rejected by the secure token device. 

1 7. The method of claim 9 wherein the service provider is an Internet Service 
25 Provider (ISP). 

1 8. The method of claim 1 3 wherein the secure token device is a smart card. 

19. The method of claim 13 wherein the secure token device is an ibutton. 



30 
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20. In a computer system wherein a service provider provides services to a customer 
and wherein the customer uses a secure token device holding tokens representing 
currency to access the services, a method of comprising the steps of: 

with the service provider, providing services to the customer during a session; 
5 assessing a charge to the customer for the services that were provided during the 

session; and 

receiving some of the tokens from the secure token device at the service 
provider, wherein the received tokens constitute payment for covering the charges to the 
customer from the secure token device. 

0 

2 1 . The method of claim 20 wherein the service provider is an Internet Service 
Provider (ISP) that provides the customer with access to the Internet. 



22. In a secure token device that interfaces with a computer system, wherein a user 
15 of the secure token device receives services from an Internet service provider (ISP) on 
the computer system, a method comprising the steps of: 

providing tokens representing currency on the secure token device; 
receiving a request for payment for services from the ISP; and 
forwarding at least one token from the secure token device to the ISP in response 
20 to the request. 
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23. In a network having a computer system where a user accesses services provided 
by a service provider during sessions via a connectionless protocol and a secure token 
device for enabling the user to access the services provided by the service provider, 
wherein the secure token device holds contextual information that captures a context of a 

5 last session the user had with the service provider, a computer-readable medium holding 
computer-executable instructions for performing a method, comprising the steps of: 

receiving the contextual information from the secure token device on behalf of 
the service provider; 

using the contextual information to restore the context of the last session the user 
10 had with the service provider during a current session where services are provided by the 
service provider to the user. 

24. The computer-readable medium of claim 23 wherein connectionless protocol is 
the Internet Protocol (IP). 

15 

25. The computer-readable medium of claim 23 wherein the service provider is an 
Internet Service Provider (ISP) that provides the user with access to the Internet. 

26. The computer-readable medium of claim 23 wherein the contextual information 
20 identifies a web site. 
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27. In a system where a secure token device that interfaces with a computer system, 
wherein a user accesses services provided by a service provider on the computer system 
and personal information about the user is provided in the storage of the secure token 
device, a computer-readable medium holding computer-executable instructions for 

5 performing a method comprising the steps of: 

establishing what portion of the personal information is permitted to be given to 
the service provider upon request; 

receiving a request from the service provider at the secure token device to obtain 
at least some of the personal information about the user; and 
10 in response to the request, sending to the service provider only information from 

the portion of the personal information that is permitted to be sent to the service 
provider. 

28. The computer-readable medium of claim 27 wherein the information that is sent 
1 5 to the provider includes less than all of the information requested. 

29. The computer-readable medium of claim 27 wherein when the service provider 
requests only information that is not permitted to be given to the service provider, the 
request is rejected by the secure token device. 

20 

30. The computer-readable medium of claim 27 wherein when the service provider 
requests only information that is not permitted to be given to the service provider, the 
request is rejected by the secure token device. 

25 31. The computer-readable medium of claim 27 wherein the service provider is an 
Internet Service Provider (ISP). 

32. The computer-readable medium of claim 27 wherein the secure token device is a 
smart card. 
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33. The computer-readable medium of claim 27 wherein the secure token device is 
an ibutton. 

34. In a computer system where a service provider provides services to a customer 
5 and wherein the customer uses a secure token device holding tokens representing 

currency to access the services, a computer-readable medium holding computer 
executable instructions for performing a method, comprising the steps of: 

with the service provider, providing services to the customer during a session; 

assessing a charge to the customer for the services that were provided during the 
10 session; and 

receiving some of the tokens from the secure token device at the service 
provider, wherein the received tokens constitute payment for covering the charges to the 
customer. 



15 35. The computer-readable medium of claim 34 wherein the service provider is an 
Internet Service Provider (ISP) that provides the customer with access to the Internet. 

36. A secure token device, comprising: 

a storage for storing at least one program that facilitates access to services 
20 provided by an Internet Services Provider (ISP), wherein the ISP provides a user with 
access to the Internet; 

a processor for executing programs stored in the storage. 



37. The secure token device of claim 36 wherein the storage holds personal 
25 information regarding the user and a set of permissions that identify what portions of the 
personal information may be sent to respective requesters when requested and a program 
that responds to requests by the ISP for the personal information to review the 
permissions and determine what portion of the personal information should be sent to 
the ISP in view of the permissions. 
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38. The secure token device of claim 36 wherein the storage holds contextual 
information that captures a context of a last session between the user and the ISP. 

39. The secure token device of claim 36 wherein the storage holds tokens 
5 representing electronic currency. 

40. The secure token device of claim 39 wherein the storage holds a program for 
forwarding a token from the storage to the ISP to cover payment of services by the ISP 
to the user. 

10 

41 . The secure token device of claim 36 wherein the secure token device is a smart 
card. 

42. The secure token device of claim 36 wherein the secure token device is an 
15 ibutton. 

43. A system comprising: 

a secure token device for a user, said secure token device holding a program for 
enabling the user to access services provided by an Internet Service Provider (ISP), 
20 wherein the ISP provides the user with access to the Internet; 

a computer system for enabling a user to gain access to services provided by the 

ISP; 

a reader interfaced with the computer system for interfacing the secure token 
device to gain access to the computer system and services provided by the ISP; and 
25 a remote computer system that acts on behalf of the ISP to provide services to 

the user. 

44. The system of claim 43 wherein the secure token device is a smart card. 



30 



45. 



The system of claim 43 wherein the secure token device is an ibutton. 
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46. A computer system wherein a user accesses services provided by a service 
provider during a during sessions via a connectionless protocol and a secure token 
device is provided for the user, said secure token device holding contextual information 
that captures a context of a last session that user had with the service provider, said 

5 computer system comprising: 

interface means for interfacing with the secure token device to facilitate 
communications between the computer system and the secure token device; 

means for receiving the contextual information from the secure token device; and 
means for using the contextual information to restore the context of the last 
1 0 session the user had with the service provider during a current session where services are 
provided by the service provider to the user. 

47. The computer system of claim 1 wherein the connectionless protocol is the 
Internet Protocol (IP). 

15 

48. The computer system of claim 46 wherein the secure token device is a smart 
card. 
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